Pull Request Test Coverage Report for Build 15006433657

Details

• 12 of 12 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 88.02%

Totals
Change from base Build 14889016103:	0.2%
Covered Lines:	720
Relevant Lines:	818

💛 - Coveralls

Thinking about the message in the UI: can we surface which credential is revoked, or just that "a credential" is revoked? In scenarios where the proof-request includes more than one credential restriction (e.g.: Person credential and LSBC credential for BCGov's lawyer use-case) it would be helpful to know which credential did not pass the revocation check. If this is not possible, we may just want to update the message to indicate that one or more crdentials that are part of the response to the proof-request ae revoked.

Ya we can get the cred_def_id so from there we can get the tag. Would that be enough or is there something else we would need?

For missing: I do not think that use-case is currently possible, at least not with BC Wallet, as you would be prevented from submitting the response if you don;t hold all the credentials that are required. In general, it could be that the proof-request requires one or more credentials and the response does not send the correct ones in the response - unsure on how likely this scenario is though.

Thinking about the message in the UI: can we surface which credential is revoked, or just that "a credential" is revoked? In scenarios where the proof-request includes more than one credential restriction (e.g.: Person credential and LSBC credential for BCGov's lawyer use-case) it would be helpful to know which credential did not pass the revocation check. If this is not possible, we may just want to update the message to indicate that one or more crdentials that are part of the response to the proof-request ae revoked.

Ya we can get the cred_def_id so from there we can get the tag. Would that be enough or is there something else we would need?

For troubleshooting purposes knowing the cred_def_id would certainly be helpful as it would allow us to figure out which credential is causing the verification to fail.

I realized that the revoked field I am using is unfortunately not only filled for revoked fields based on further testing. Jamie has suggested trying to use the /issued/details endpoint so I will try migrating the is_revoked method to using it

What should be informing us about the revoked credential is the verified_msgs we get back which seem to be empty. I have opened an issue to track the handling of this openwallet-foundation/acapy#3724

For more context see https://github.com/openwallet-foundation/acapy/blob/main/open-api/swagger.json#L13336